This is a continuation of #1617
(superseded and closed by this PR), with a lot of the work being done by
@luca-patrignani.

# Conditional Blocks
This PR implements Conditional Blocks, which are a native way of
semantically expressing conditional branching in an SDFG. This replaces
the traditional "state machine only" way of expressing conditional
branching, with two main goals:
1. **Simplify SDFG analysis and optimization by clearly exposing
conditional branching.** Previously, detecting and treating conditional
branches required expensive analysis of the control flow graph
structure, which had to be performed repeatedly and was error prone. By
contrast, Conditional Blocks can be generated by a frontend using
semantic information from the source language, entirely circumventing
this step.
2. **Address code generation issues.** Code generation relies on a
series of control flow detections to generate appropriate code that is
not full of `goto` statements for each state transition. However, just
as in the above issue, this process is error prone and often leads to
invalid code being generated for complex control flow constructs (e.g.,
conditionals inside of loops with conditional break, continue, return,
etc.). By exposing _all_ regular control flow (i.e., loops and
conditional branching) with native SDFG constructs, this step can be
skipped in code generation.

### Anatomy of Conditional Blocks
`ConditionalBlock`s are a type of `ControlFlowBlock` which contains a
series of **branches**. Each branch is represented by a full
`ControlFlowRegion` and has a condition in the form of a `CodeBlock`
attached to it. When a `ConditionalBlock` is executed, the conditions
are checked in the insertion order of the branches, and if a matching
condition was found, that branch (and only that branch) is executed.
When the executed branch finishes executing, the `ConditionalBlock`'s
successor is next. If no condition matches, no branch is executed.

The condition for a single branch at a time may be `None`, which
represents a wildcard or `else` case that is executed if no conditions
match.

### Code Generation Changes
Code generation (when using this feature) is drastically simplified with
respect to control flow: no more control flow detection is performed.
Instead, regular control flow constructs are only generated from the new
native SDFG constructs
([`LoopRegion`s](#1475) and
`ConditionalBlock`s), and any other state transition is either only used
for sequential ordering (unconditional transitions to a single, direct
successor), or leads to a `goto`. This makes code generation
significantly less error prone and simpler to work with.

### Compatibility
This feature is implemented minimally invasive and with full backwards
compatibility for now.
Just as with [`LoopRegion`s](#1475),
this feature is only used if an explicit `use_experimental_cfg_blocks`
flag is set to `True` in compatible frontends (currently only Python
frontend, Fortran frontend integration is coming soon).

If an SDFG makes use of these experimental blocks, some passes and
transformations will no longer be applied automatically in pipelines.
Transformations that handle these blocks correctly can be explicitly
marked with `@transformation.experimental_cfg_block_compatible` to apply
them on SDFGs with experimental blocks.

### Inlining
Conditional blocks can be inlined through a utility function to
traditional SDFG state machines. This is automatically done by
compatible frontends if the experimental CFG blocks feature is turned
off.

### Visualization Components
The visualization components are being worked on separately in
spcl/dace-webclient#173. This PR does not depend
on the visualization components to be merged.

---------

Co-authored-by: Luca Patrignani <[email protected]>
Co-authored-by: luca-patrignani <[email protected]>